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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines interworking procedures between a 3GPP CS domain (see 3GPP TS 23.205 [2]) which 
apphes either BICC or ISUP as signalHng protocol, and external networks that use SIP-I (see ITU-T Q. 1912.5 [20], 
Profile C) as signalling protocol. The document also describes the related interworking architecture. The control plane 
interworking is performed by an interworking unit at the interconnection between the 3GPP CS domain and an external 
SIP-I network. The user plane interworking is performed by an MGW. The present document defines stage 2 
procedures for the control of the MGW. 

The present specification reuses existing interworking procedures of 3GPP TS 29.163 [4] and ITU-T Q. 1912.5 [20], 
Profile C, as far as possible. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1], in 

3GPP TS 29.163 [4], in ITU-T E.164 [9], in ITU-T Q.1912.5 [20] and the following apply. A term defined in the 

present document takes precedence over the definition of the same term, if any, in any other of the specifications listed 

above. 

Interworking Unit (IWU): Logical entity that interworks SIP-I signalHng with BICC or ISUP signalhng in the 3GPP 
CS Domain. 

Incoming Interworking Unit (I-IWU): Logical entity that terminates incoming calls from the external SIP-I network 
side and originates outgoing calls towards the CS Domain side using the BICC or ISUP protocols. 

Outgoing Interworking Unit (O-IWU): Logical entity that terminates incoming BICC or ISUP calls from the CS 
Domain side and originates outgoing calls towards external SIP-I network. 

External SIP-I signalling function: function in the external network, which has the capabilities to process SIP with 
encapsulated ISUP messages. 



For references to 3GPP TS 29.163 [4] procedures within the present specification, the MGCF in 3GPP TS 29.163 [4] is 
to be understood as IWU. The IM-MGW is to be understood as MGW. The Mn interface is to be understood as 
interface between IWU and MGW. The IM CN subsystem is to be understood as external SIP-I network. The CS 
network is to be understood as 3GPP CS domain. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1], in 3GPP TS 29.163 [4], in 
ITU-T E.164 [9], in ITU-T Q.1912.5 [20], and the following apply. An abbreviation defined in the present document 
takes precedence over the definition of the same abbreviation, if any, in any other of the specification listed above. 

IW-MGW Interworking Media Gateway Function 



4 Network cliaracteristics 

4.1 Key characteristics of ISUP/BICC based CS Domain 

The 3GPP CS domain uses either BICC Capability Set 2 (see ITU-T Q.1902.1 to Q.1902.6 [19] and Q.765.5 [17]) with 
3GPP specific extensions, as specified for the 3GPP Nc interface in 3GPP TS 29.205 [5], or ISUP (see ITU-T Q.761 to 
Q.764 [15]), as signalling protocol. 

If BICC is used as signalling protocol, the 3GPP Nb interface, as specified in 3GPP TS 29.414 [7] and 3GPP TS 29.415 
[8], is used for the user plane transport. If ISUP is applied as signalling protocol, TDM transport of the user plane is 
applied. 

4.2 Key characteristics of external SIP-I network 

The external SIP-I network applies SIP, IETF RFC 3261 [32], with ISUP encapsulated according to IETF RFC 3204 
[31], as specified in ITU-T Q.1912.5 [20] Profile C. The SIP Signalhng Profile defined for Profile C in Annex C of 
Q.1912.5 is applied. 

The network uses either IPv4 (IETF RFC 791 [24]) or IPv6 (IETF RFC 2460 [27]). 
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For the transport of most media, RTP (IETF RFC 3550 [36]) over UDP (IETF RFC 768 [25]) is applied. 

For the transport of control signalhng, UDP (IETF RFC 768 [25]), TCP (IETF RFC 793 [26]) or SCTP (IETF RFC 
2960 [29]) can be used. 



5 Interworking reference model 

Figure 5.1 details the interworking reference model for the present specification 
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NOTE 1 : If needed a SGW is applied for conversion (botli ways) of tlie transport level between the IWU and the 
(G)MSC. The SGW may be implemented as a stand-alone entity or it may be located in another entity of 
the CS Domain. A SGW function is not required for certain signalling transports, where MSUA+SCTP+IP is 
used in CS network and IWU. The implementation options are not further discussed in the present 
document. 

NOTE 2: The IWU is a logical function that may reside with other 3GPP logical functions in the same physical 
nodes, e.g. in an (G)MSC Server. The figure shows only the logical separation. 

Figure 5.1 : interworking reference model 



Control plane interworking 



6.1 



General 



The following sub-clauses define the signalling interworking between the Bearer Independent Call Control (BICC) or 
ISDN User Part (ISUP) protocols and Session Initiation Protocol (SIP) with its associated Session Description Protocol 
(SDP) and encapsulated ISUP at an IWU. 

The IWU shall act as a Type A or Type B exchange (ITU-T Q.764 [15]) for the purposes of ISUP and BICC 
compatibility procedures. 
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The BICC/ISUP capabilities or signalling information defined for national use are outside the scope of the present 
document. 

The interworking procedures are based on ITU-T Recommendation Q. 1912.5 [20] profile C. Clarifications are made 
within this specification on the application of Q. 1912. 5 profile C. 

NOTE: An IWU may apply additional procedures to support interworking for national-specific capabilities. 

The services that can be supported through the use of the signalling interworking are limited to the services that are 
supported both within the BICC or ISUP based 3GPP CS domain and the external SIP-1 network. The IWU will 
originate and/or terminate services or capabilities that do not interwork seamlessly across domains according to the 
relevant protocol recommendation or specification. 

Table 6.1.1 lists the services seamlessly interworked within the scope of the present document. 

Table 6.1.1: Service Interworking Capabilities 



Service 



Speech/3.1 kHz audio 



Data Calls (optional) 



En bloc address signalling 



Out of band transport of DTIVIF tones and information. (BICC only) 



Inband transport of DTMF tones and information. (BICC and ISUP) 



IVIultiple Subscriber Number (IVISN) 



Calling Line Identification Presentation (CLIP) 



Calling Line Identification Restriction (CLIR) 



Connected line presentation (COLP) 



Connected line restriction (COLR) 



Call Hold 



Call Forwarding 



Explicit Call Transfer (ECT) 



User-to-User Signalling (UUS) 



Call Deflection (CD) 



Closed User Group (CUG) 



Completion of Calls to Busy Subscriber (CCBS) 



Multi-Level Precedence and Pre-emption (MLPP) 



Call Waiting 



The Clause 5.3.2 of ITU-T Q. 1912.5 [20] describes additional general principles specific to SIP-I. 



6.2 Interworking between CS Domain using ISUP signalling and 
external network using SIP-I signalling 

6.2.1 Control Plane Interworking 

The control plane between CS networks supporting ISUP and the external network using SIP-I, where the underlying 
network is TDM or ATM and IP respectively, is as shown in figure 6.2. 1. 



£75/ 



3GPP TS 29.164 version 8.1.0 Release 8 



11 



ETSI TS 129 164 V8.1.0 (2009-06) 







ISUP 




^-^..^^^^-^ 


NNI 




ISUP 


ISUP 


SIP-I 


^SIP-I 




SIP-I 




TDM 




IP 




MTP3 


MTP3 


TCP/ 
UDP / 
SCTP 


TCP/ 
UDP/ 
SCTP 


MTP2 


MTP2 


LI 


LI 


IP 


IP 


V. 


3GPP PLMN 




V, 




(G)MSC 




Interworking Unit 




External SIP-I 

signalling 

function 

External SIP-I 



Figure 6.2.1 : Control plane interworking between CS networks supporting ISUP 
and an external network using SIP-I signalling 

6.2.2 Services performed by network entities in tine control plane 



6.2.2.1 



Services of the IWU 



The IWU shall provide the interaction, through the use of its interworking function, between the SS7 MTP3 [13] -User 
part information and SIP-1. The IWU shall also provide the encapsulation from the SS7 MTP3-User part information to 
the SIP-I ISUP MIME and de-encapsulation from this ISUP MIME to the SS7 MTP3-User part information. 

6.2.2.1 Services of the external SIP-I signalling function 

The external SIP-I signalling function is a remote SIP User Agent capable of processing ISUP. 

6.2.3 Signalling interactions between network entities in the control plane 



6.2.3.1 



Signalling between the IWU and SIP-I signalling function 



Signalling between the SIP-I signalling function and the IWU uses the services of IPv4 (IETF RFC 791 [24]) or IPv6 
(IETF RFC 2460 [27]), transport protocol such as TCP (IETF RFC 793 [26]) or UDP (IETF RFC 768 [25]) or SCTP 
(IETF RFC 2960 [29]), and SIP-I. 

6.2.4 SIP-ISUP protocol interworking 

6.2.4.1 Incoming call interworking from SIP-I to ISUP at l-IWU 



6.2.4.1.1 



General 



The procedures for Profile C in Clause 6 of ITU-T Q- 1912-5 [20] shall be applied with the modifications provided in 
this Clause. 



6.2.4.1.1 



Interworking of received ISUP messages to SIP messages 



The I-IWU receiving backwards ISUP information shall apply any interworking procedures detailed in Clause 6 of 
ITU-T Q-1912-5 [20] affecting parameters within the ISUP, and then proceed to encapsulate any ISUP information 
received (with the exception of the excluded messages detailed in 5.4.3 of ITU-T Q-1912-5 [20]) in a SIP message in a 
MIME body according to IETF RFC 3204 [31]. The selected SIP Header fields relating to the handling of the ISUP 
body shall be set as specified in Clause 5.4.1.2 of ITU-T Q-1912-5 [20]. 
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6.2.4.1 .2 Receipt of encapsulated ISUP information within SIP 

On receipt of a SIP message containing encapsulated ISUP, the IWU shall de-encapsulate the ISUP message from the 
SIP message body. The received SIP message shall be mapped to an ISUP message and merged with the de- 
encapsulated ISUP message according to the rules for Profile C in Clause 6 of ITU-T Q. 1912.5 [20]. 

NOTE 1 : These precedence rules have been derived from the following principles, which can also be applied for 
any ISUP information not covered by the present specification: 

1 Where a SIP header mapping to ISUP field(s) is possible (for example the mapping of Request-URI to 
Called Party Number), the SIP header is given precedence over the encapsulated ISUP value in the 
alignment process. (Conflicts can be caused by a possible service invocation within the external SIP-I 
network.) 

2 De-encapsulated ISUP information overrides ISUP information derived from default values (rather 
than SIP information). 

3 Local ISUP procedures may modify information derived from SIP or default values. 

This note has been derived from text in ITU-T Q. 1912.5 [20], Clause 5.4.2. 

NOTE 2: There is a certain change against Q. 1912.5, where the above note is formulated as normative procedures. 
However, this is very high level and not required if you look at the real interworking procedures later on. 
Therefore formulating this as a note makes much more sense. 



6.2.4.1 .3 Special Procedures for the Reception of SIP INVITE request 

6.2.4.1 .3.1 Propagation of overlap signalling toward the 3GPP CS domain 

The procedures in Clause 6 of ITU-T Q. 1912.5 [20] related to the propagation of overlap signalling across the I-IWU 
shall not be applied. 

NOTE: A G-MSC acting as IWU will collect all digits required to identify the callee and not propagate the 
overlap signalling further. Therefore, it will not apply procedures in ITU-T Q. 1912. 5 [20] Clause 6 
related to the propagation of overlap signalling. 

6.2.4.1 .3.2 Derivation of TMR, USI and HLC parameters within send lAM message 

The I-IWU may choose to transcode media and shall then set the parameters according to the coding applied within the 
CS Domain. Otherwise, the I-IWU shall select a codec for the SIP side termination using SDP offer-answer procedures, 
IETF RFC 3264 [34], and shall map the SDP information of this codec to the TMR/USI/HLC parameters according to 
table 2a of 3GPP TS 29.163 [4]. If the information derived from this mapping matches the information in the 
TMR/USI/HLC parameters in the encapsulated ISUP, the TMR/USI/HLC parameters from the encapsulated ISUP 
should be used as they may contain additional information. If the information derived from this mapping contradicts the 
information in the TMR/USI/HLC parameters in the encapsulated ISUP, the TMR/USI/HLC parameters derived by the 
mapping shall be used. 

NOTE: The procedures in this note are an amendment compared to ITU-T Q. 1912.5, which simply states the 
TMR parameters in encapsulated ISUP shall take precedence. However this is inappropriate if an 
incompatible codec is selected. 

6.2.4.1 .3.3 Receipt of SIP INVITE without SDP offer 

An IWU may reject receipt of SIP INVITE without SDP offer, otherwise the procedures in this paragraph shall be 
followed. 

Upon receipt of the first INVITE with sufficient digits for an lAM to be sent, but without an SDP offer (see IETF 
RFC3264 [34]), the I-IWU shall construct an SDP offer with contents according to local policy, e.g. SDP for a G711 
speech call. The IWU may use the TMR and USI parameters of the encapsulated lAM to determine the desired service 
and construct the SDP offer accordingly. 
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1) If reliable provisional responses (see IETF RFC 3262 [33]) are supported in the external SIP-I network, the 
I-IWU should immediately send the SDP offer within a 183 Session Progress message. The I-IWU should send 
the lAM upon receipt of the SDP answer and may take into account the media selected in the answer when 
constructing the lAM. 

2) If reliable provisional responses are not supported, the I-IWU should immediately send out the lAM. The I-IWU 
will also include the SDP offer in the 200 OK(INVITE) SIP messages according to SIP procedures. 

NOTE: The text in the preceding paragraph has been derived from ITU-T Q. 1912.5 [20], Clause 6.1.1. 

Compared to ITU-T Q. 1912.5, the recommendation has been added that for an incoming INVITE without 
media the TMR/USI is considered to select media. Furthermore, bullet 1 recommends to wait for the SDP 
answer to construct TMR, USI and BICC codec list accordingly. 

6.2.4.2 Outgoing Call Interworking from ISUP to SIP-I at 0-IWU 

6.2.4.2.1 General 

The procedures for Profile C in Clause 7 of ITU-T Q- 1912-5 [20] shall be applied with the modifications provided in 
this Clause. 

6.2.4.2.2 Sending of ISUP information to adjacent SIP nodes 

The I-IWU receiving ISUP information shall apply any interworking procedures detailed in Clause 7 of ITU-T Q-1912- 
5 [20] affecting parameters within the ISUP, and then proceed to encapsulate any ISUP information received (with the 
exception of the excluded messages detailed in 5.4.3 of ITU-T Q-1912-5 [20]) in a SIP message in a MIME body 
according to IETF RFC 3204 [31]. SIP Header fields relating to the handling of the ISUP body shall be set as specified 
in 5.4. 1.2 of ITU-T Q-1912-5 [20]. 

NOTE: The text in the preceding paragraph has been derived from ITU-T Q. 1912.5 [20], Clause 5.4.1. 

For a basic call setup, the SIP message used to encapsulate the ISUP message shall be the SIP message that was first 
triggered to be sent from the IWU as a result of the interworking specified in Clause 7 of ITU-T Q-1912-5 [20]]. As an 
example, this means that an ISUP lAM will be encapsulated within the INVITE message that is sent out from the 
O-IWU. For the ISUP messages listed in Table 1 of ITU-T Q. 1912.5 [20], the special procedures in Clause 5.4.3 of 
ITU-T Q.1912.5 are appHcable. 

NOTE: The text in the preceding paragraph has been derived from ITU-T Q.1912.5 [20], Clause 5.4.1.3. 

6.2.4.2.3 Receipt of encapsulated ISUP information within SIP-I 

On receipt of a SIP message containing encapsulated ISUP, the IWU shall de-encapsulate the ISUP message from the 
SIP message body. The received SIP message shall be mapped to an ISUP message and merged with the de- 
encapsulated ISUP information according to the rules in in Clause 7 of ITU-T Q-1912-5 [20]. 

NOTE: The text in the preceding paragraph has been derived from ITU-T Q.1912.5 [20], Clause 5.4.2. 

NOTE: These precedence rules have been derived from the following principles, which can also be applied for 
any ISUP information not covered by the present specification: 

1 Where a SIP header mapping to ISUP field(s) is possible (for example the mapping of Request-URI to 
Called Party Number), the SIP header is given precedence over the encapsulated ISUP value in the 
alignment process. (Conflicts can be caused by a possible service invocation within the SIP network.) 

2 De-encapsulated ISUP information overrides ISUP information derived from default values (rather 
than SIP information). 

3 Local ISUP procedures may modify information derived from SIP or default values. 

This Note has been derived from text in ITU-T Q.1912.5 [20], Clause 5.4.2 

NOTE There is a certain change against Q.1912.5, where the above note is formulated as normative procedures. 
However, this is very high level and not required if you look at the real interworking procedures later on. 
Therefore formulating this as a Note makes much more sense. 
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6.2.4.2.4 



Special procedures related to outgoing INVITE 



6.2.4.2.4.1 Overlap Signalling 

The O-IWU does not need to support procedures related to overlap signalling in Clause 7 of ITU-T Q-1912-5 [20]. 
NOTE: No overlap signalling is used in a 3GPP CS domain. 



6.2.4.2.4.2 



Coding of encapsulated ISUP JAM parameters in outgoing INVITE 



The O-IWU may choose to transcode media, or attempt to interwork media without transcoding. If the O-IWU 
transcodes, it should set the TMR/USI/HLC parameters according to the codec applied in the SIP-I network. Otherwise, 
it should provide the TMR/USI/HLC parameters as received in the incoming lAM. If the I-IWU offers several codecs 
within SDP, it should set the TMR/USI/HLC parameters according to the preferred codec, applying the rules above for 
this codec. 

NOTE: ITU-T Q. 1912.5 [20] does not describe the relationship between TMR/USI/HLC and SDP codec 
negotiation. 

6.2.4.2.4.3 Media offered in SDP of outgoing INVITE 

The O-IWU should offer codecs known to be supported within the external SIP-I network. 

6.3 Interworking between CS Domain using BICC signalling 
and external network using SIP-I signalling 

6.3.1 Control Plane Interworking 

The control plane between CS networks supporting BICC and the external network using SIP-I, where the underlying 
network is SS7 and IP respectively, is shown in figures 6.3.1 and 6.3.2 in accordance to TS 29.202 [37]. 
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Figure 6.3.1 : Control plane interworking between CS networks supporting BICC/IP 
and an external network using SIP-I signalling 
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Figure 6.3.2: Control plane interworking between CS networks supporting BICC/ATM 
and an external network using SIP-I signalling 

For signalling interactions between network entities in the control plane see Clause 6.2.3. 

6.3.2 SIP-BICC protocol interworking 
6.3.2.1 General 

Specific rules for handling of the APM mechanism have been added, which are not specified in ITUT Q. 1912.5 [20]. 

The procedures in Clause 6.2.4 shall be applied with the modifications provided the present Clause. 

The text in Clause 6.2.4 is to be understood as follows: 

Where "ISUP" is mentioned, this shall be understood as BICC. As an exception, references to ISUP encapsulated 
within SIP-I shall be understood without modification, i.e. they still refer to ISUP rather than BICC. 



6.3.2.2 



Incoming call interworking from SIP to BICC at l-IWU 



An APM messages received from the CS side (see ITU-T Q.765 [16]) that relates to the BICC APM user (see ITU-T 
Q.765.5 [17]) shall not be encapsulated in any triggered SIP message. 



6.3.2.3 



Outgoing Call Interworking from BICC to SIP at 0-IWU 



If an lAM message is received, the APM information elements (see ITU-T Q.765 [16]) relating to the BICC APM user 
(see ITU-T Q.765.5 [17]) shall be removed before the lAM message is encapsulated in the triggered SIP INVITE 

message. 

An APM messages received from the CS side (see ITU-T Q.765 [16]) that relates to the BICC APM user (see ITU-T 
Q.765.5 [17]) shall not be encapsulated in any triggered SIP message. 

6.4 Supplementary services 

6.4.1 Special procedures for supplementary service interworking 

The supplementary services described in Table 6.1.1 are interworked by using the parameters of the (de)encapsulated 
ISUP. No other interworking is required, except if otherwise described within the clauses below. 
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6.4.2 Interworking of CLIP/CLIR supplementary service 

At the O-IWU: the service shall be supported by encapsulation. 
At the I-IWU: ITU-T Q. 19 12.5 [20], Annex B.l, shall apply. 

6.4.3 Interworking of Call Hold (HOLD) supplementary service 

The Profile C procedures in ITU-T Q. 19 12.5 [20], Clause BIO, shall be followed. 

6.4.4 Interworking of Completion of Calls to Busy Subscriber (CCBS) 
supplementary service to SIP networks 

The Profile C procedures of ITU-T Q.1912.5 [20], Clause B.ll shall be appHed. 



7.1 



User plane Interworking 



ISUP based CS Domain 



Figure 7.1.1 shows the user plane protocol stacks within the SIP-I network and an ISUP based CS Domain. 
Apart from speech codecs, data call related codecs, e.g. as listed in Table 2a of 3GPP TS 29.163 [4], may be used. 

Transc oding o r Relay 




7.2 



Figure 7.1.1 : User Plane Interworking and ISUP based CS Domain 



BICC based CS Domain 



Figure 7.2.1 shows the user plane protocol stacks within the SIP-I network and an BICC based CS Domain. 

Apart from speech codecs, data call related codecs, e.g. as listed in Table 2a of 3GPP TS 29.163 [4], may be used. 

Within the CS domain, the Nb interface as specified in 3GPP TS 29.414 [7] and 3GPP TS 29.415 [8] is used. 

If the same codec is used on both sides, no transcoding is required. If no transcoding is performed, the procedures in 
Clause 8.1.1 of 3GPP TS 29.163 [4] shall be applied to interwork the Nb framing Protocol, as specified in 3GPP TS 
29.415 [8], with RTP, as specified in IETF RFC 3550 [36]. 
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Figure 7.2.1 : User Plane Interworking for BICC based CS Domain 



8 



Interactions between control node and MGW 



8.1 



Overview 



ITU-T H.248.1 [11] with 3GPP specific extensions as detailed in 3GPP TS 29.332 [6] shall be appHed as signalHng 
protocol between IWU and MGW. 

The present specification describes the signalling procedures between IWU and MGW and their interaction with 
BICC/ISUP and SIP signalling in the control plane, and with user plane procedures. 3GPP TS 29.332 [6] maps these 
signalling procedures to H.248 messages and defines the required packages and parameters. 



8.2 Signalling interactions 



The procedures in Clause 9.2 of TS 29.163 shall be applied with modifications provided in the present Clause. 

8.2.1 Backward through-connection for outgoing call interworking from 
BICCtoSIPatO-IWU. 

For the outgoing call interworking from BICC to SIP at O-IWU, the IWU shall not request the MGW to provide an 
awaiting answer indication (ringing tone) to the calling party, as specified in Clauses 9.2.3.1.5, 9.2.3.2.5 and 9.2.3.3.5 of 
3GPP TS 29.163 [4]. The O-IWU shall instead request the MGW to backward-through connect using the "Change-IMS 
Through-Connection" procedure when the trigger conditions in those clauses apply. 

8.2.2 Handling of RTP telephone events 

The procedures in Clause 9.2.8 of 3GPP TS 29.163 [4], are applicable with the following modifications: 

It depends on the characteristics of the external SIP-I network if DTMF is transported within the codec or according to 
IETF RFC 4733 [28]. SIP-I transports DTMF within the RTP telephony event according to RFC 4733 [28] if the RTP 
telephony event payload type is negotiated between the peer SIP-I entities; alternatively, if the RTP telephony event 
payload has not been negotiated, SIP-I may transport the DTMF in-band ("within the codec") when the selected codec 
allows transparent DTMF transport. 

The control node indicates the transport mode of DTMF to the MGW as follows in the "Configure IMS Resources" 
procedure or "Reserve IMS Connection Point and Configure Remote Resources" procedure (signal 1 in figure 48 or 
figure 49 of 3GPP TS 29.163 [4]): 
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If the control node does not configure the RTP telephony event payload at the MGW, then the Detect DTMF 
procedure means in-band ("within the codec") detection and sending of DTMF. 

If the control node configures the RTP telephony event payload at the MGW, then the Detect DTMF procedure 
means extracting and sending DTMF within the RTP payload type according to IETF RFC 4733 [28]. 

Editor's Note: The above reference contains sequences that require the MGW to forward partial digits to the Server. 
It is not yet agreed if this shall be permitted or if the MGW shall only forward complete and valid digits. 

8.3 Signalling procedures 

The procedures in Clause 9.3 of 3GPP TS 29. 163 shall be applied with modifications provided in the present Clause. 
The support of the "Send TDM Tone", "Stop TDM Tone", "Send Tone" and "Stop Tone" procedures is optional. 
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Annex A (normative): 

Codec Negotiation between a BICC based CS Domain and 

an external SIP-I network 

The procedures in Annex B of TS 29.163 [4] are applicable when the IWU receives from the external SIP-I based 
network an SDP offer without the 3GPP_OoBTC_lndicator as defined in 3GPP TS 29.231 [38]. 

If the IWU receives from the external SIP-I based network a SIP request with an SDP offer containing a codec list with 
the 3GPP_OoBTC_lndicator, the IWU may apply the procedures in accordance to subclause 6.6.2 of 3GPP TS 29.235 
[39]. 

When the IWU sends a SIP request with an SDP offer towards the external SIP-I based network, the IWU may include 
the 3GPP_OoBTC_lndicator in accordance to subclause 6.6.3 of 3GPP TS 29.235 [39]. 
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